Patching is the process of modifying already-installed programs, including application programs, utility programs, operating systems and operating system components, device drivers, etc. Patching can be useful to modify programs for a variety of purposes, including correcting a programming error, reducing or eliminating a security risk, or improving the logic used by the modified program. Patching is typically initiated by the company or other organization that originally supplied the program to be patched.
Installed programs are predominantly composed of executable code modules. As one example, many programs designed to execute on the WINDOWS XP operating system from Microsoft Corp. of Redmond, Wash. are predominantly composed of executable code modules called “DLLs.” One popular conventional approach to patching is to identify, among the executable code modules making up the installed program to be patched, the executable code module containing the program code that one wishes to modify with a patch; creating a new version of the identified executable code module in which the desired modification is made; and distributing the new version of the identified executable code module, together with an installer program, to users who may wish to apply the patch. Each user then determines whether s/he wishes to apply the patch, and if so, executes the installer program, which replaces the original version of the identified executable code module with the new version of the identified executable code module.
Conventional approaches to patching have a number of significant disadvantages. These disadvantages often increase the burden associated with receiving and applying patches. In some cases, this increased burden delays the application of some patches by some users, and even prevents the application of some patches by some users. Such delay and prevention in the application of patches can in some cases have serious negative consequences for users, especially for patches designed to reduce or eliminate a security risk.
One disadvantage of conventional approaches to patching relates to common cases in which multiple patches must be created and distributed to effect a single modification to a single program. In some cases, the program to be patched has several different “flavors” of a particular executable code module, such as a different flavor for each operating system or operating system version on which the program is designed to execute, and/or each natural language version of the program. Where the identified executable code module is such an executable code module, the patch creation and distribution process described above must be repeated for each flavor of the identified executable code module. The user must then select and apply the patch for the appropriate flavor of the identified executable code module. Sorting through the resulting large number of patches and selecting the proper set of patches for application on each user's computer system can be very burdensome, so much so that this condition is sometimes called “patch hell.” In some cases, an administrator must maintain an inventory database identifying the set of executable module versions installed on each target system, which is used to select appropriate conventional patches for each target system.
Another disadvantage of conventional approaches to patching relates to the large size of the distributed patches. It is not uncommon for executable code modules to have a size measured in megabytes, which in turn causes a single patch to have a comparable size, making it unwieldy to distribute and store, or even impossible to distribute and store, for some users. This problem can be multiplied for patches having multiple flavors. Further, because each conventional patch typically includes an entire substitute executable module, applying conventional patches can contribute to the problem of code churn.
A further disadvantage of conventional approaches to patching relates to a need by some users to test patches before applying them to production computer systems. In some cases, installing a patch on a computer system can have adverse results, such as where the new version of the identified executable code module contained in the patch introduces a new programming error, or where it causes a new, unpredicted interaction with another program running on the computer system against which it is applied. Accordingly, often before applying a patch against a production system whose data and operation are important to sustain, the user first applies the patch against a testing system to evaluate whether the patch is safe to apply to the production system. Such separate testing of patches adds to the burden associated with patching. Additionally, where a conventional patch creates a problem—such as an application compatibility problem or a new exploit vulnerability—at a time substantially after the patch is applied, it can be difficult to trace such problems back to the patch.
An additional disadvantage of conventional approaches to patching relates to the operation of the installer included in the patch. Often, in order to replace an executable code module that is part of executing program, the installer must first terminate execution of that program. Also, in some cases, such replacement cannot be completed without restarting the computer system. Both of these steps can cause substantial disruptions in the use of the patched computer system.
Another disadvantage of conventional approaches to patching involves attempting to patch an executable module for which a “private fix,” also called a “hot fix,” has earlier been issued to a proper subset of the customers for that executable module. In such cases, because of difficulties encountered in distributing conventional patches that substitute different new versions of the executable code module depending upon to each user depending upon whether the user has applied the hot fix, it is typical to instead distribute a simple conventional patch that substitute a single new version of the executable module irrespective of whether the user has applied the hot fix. If that new version embodies the hot fix, the patch imposes the hot fix on customers not intended to receive it. If, on the other hand, that new version does not embody the hot fix, it deprives the customers intended to receive the hot fix of the hot fix.
Another disadvantage of conventional approaches to patching involves the fact that the installers for software products that rely on a particular executable module, such as a particular dynamic link library, often “hide” that executable module by storing it in a non-standard location in the target computer system's filesystem. Accordingly, it is sometimes difficult or impossible to determine whether a particular target system contains a copy of an executable module to be patched, and, if so, where it resides in the target computer system's filesystem. Also, some software products maintain a “catalog” of executable module versions that have been installed by their installers. A software product may rely upon the correctness of an indication in the catalog of the version of a particular executable module. Such reliance is defeated where a conventional patch replaces the version of the executable module identified in the catalog with a new version of the executable module without updating the catalog.
Another disadvantage of conventional approaches to patching springs from the fact that they are impossible to apply at a time before the executable module to be patched is installed in the target computer system. As a result, if the executable module to be patched is installed in the target computer system after a conventional patch for that executable module is received, it is unlikely that the patch will be applied to the executable module.
Another disadvantage of conventional approaches to patching is that they typically can only be applied by a user logged in to the target computer system using an administrative account having liberal modification permissions. Logging into an administrative account for this purpose can make the target computer system vulnerable to viruses present on the target computer system seeking to modify aspects of the target computer system and requiring liberal permissions to do so.
Another disadvantage of conventional approaches to patching is that conventional patches can be difficult or impossible to disable, requiring steps such as reversing the replacement of an executable module, or reversing one or more modifications to the system registry.
Accordingly, a new approach to patching that overcame some or all of the disadvantages of conventional approaches to patching discussed above would have significant utility.